Systems and methods for transaction pre-authentication

ABSTRACT

Systems, methods, and computer-readable media are provided for mobile-based transaction pre-authorization. One example method comprises receiving, from a device (such as a mobile device), a pre-authorization request including at least selection of a payment method, and generating a pre-authorization for a purchase based on the selected payment method. The method further comprises receiving a transaction request, determining whether the received transaction request is associated with the pre-authorization, and processing the transaction request based on the determination. Systems and computer-readable media implementing the above method are also provided. User interfaces are also provided for enabling the use of such methods, systems, and computer-readable media on, for example, mobile devices.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/511,710, filed Jul. 15, 2019, which is a continuation of U.S. patentapplication Ser. No. 14/749,233, filed Jun. 24, 2015, which claims thebenefit of priority of U.S. Provisional Patent Application No.62/017,486, filed on Jun. 26, 2014, each of which is hereby incorporatedby reference in the present application.

BACKGROUND

Financial service providers regularly provide accounts to consumers thatenable the consumers to purchase goods against a line of credit. Theunderstanding with such accounts is that when the consumer makes anauthorized purchase at a merchant, the financial service provider paysthe merchant for the purchase, and the consumer will pay the financialservice provider back at some point in the future. At times, however,consumers may lose their credit cards or otherwise lose control of theiraccounts, meaning that an unauthorized individual could make fraudulentpurchases using the account.

Often times, the risk of fraudulent transactions is borne by thefinancial service provider. Thus, many financial service providers haveimplemented fraud systems that attempt to determine whether atransaction is fraudulent. For example, if a financial service providerreceives a $20.00 transaction request from a McDonald's in Arlington,Va. on Monday morning and also receives a $2,500.00 transaction requestfrom a Home Plus store in Seoul, South Korea 20 minutes later, thefinancial service provider can deny one or both transaction requestsbecause an authorized user cannot have travelled between both purchaselocations in that short amount of time.

But most cases of fraud are not so obvious, and many fraud detectionsystems are known to have an unacceptably high false positive rate.Thus, transaction requests that are legitimate may be improperly denied.For example, if a consumer attempts to purchase a new television, thepurchase may appear out of the ordinary when compared to the consumer'sother purchases. The transaction may thus be denied even if the consumerhas sufficient credit to make the purchase. This causes inconveniencefor the consumer.

There is thus a need to address these and other issues. The presentdisclosure provides methods, systems, and computer-readable media tosolve these and other issues.

SUMMARY

Disclosed embodiments include methods, systems, and computer-readablemedia configured to, for example, enable pre-authorization oftransactions that might otherwise be denied as potentially fraudulent.

In one aspect, a method of pre-authorization is provided. The methodcomprises receiving, from a device, a pre-authorization requestincluding at least selection of a payment method, and generating apre-authorization for a purchase based on the selected payment method.The method further comprises receiving a transaction request,determining whether the received transaction request is associated withthe pre-authorization, and processing the transaction request based onthe determination. Systems and computer-readable media implementing theabove method are also provided.

Aspects of the disclosed embodiments may include tangiblecomputer-readable media that stores software instructions that, whenexecuted by one or more processors, are configured to and capable ofperforming and executing one or more of the methods, operations, and thelike consistent with the disclosed embodiments. Also, aspects of thedisclosed embodiments may be performed by one or more processorsconfigured as special-purpose processor(s) based on softwareinstructions that are programmed with logic and instructions thatperform, when executed, one or more operations consistent with thedisclosed embodiments.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory onlyand are not restrictive of the disclosed embodiments, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate disclosed embodiments and,together with the description, serve to explain the disclosedembodiments. In the drawings:

FIG. 1 is a block diagram of an exemplary system, consistent withdisclosed embodiments.

FIG. 2 is a diagram of an exemplary electronic system, consistent withdisclosed embodiments.

FIG. 3A is a diagram of an exemplary interface displaying choices ofcards that a user can use in accomplishing a transaction request,consistent with disclosed embodiments.

FIG. 3B is a diagram of an exemplary interface requesting an approximateamount for a transaction request, consistent with disclosed embodiments.

FIG. 3C is a diagram of an exemplary interface displaying a confirmationthat a pre-authorization request has been approved, consistent withdisclosed embodiments.

FIG. 3D is a diagram of an exemplary interface displaying a denial of apre-authorization request, consistent with disclosed embodiments.

FIG. 4A is a flowchart of an exemplary process for pre-authorizing atransaction request using a mobile device, consistent with disclosedembodiments.

FIG. 4B is a flowchart of an exemplary process for processing atransaction request initiated at a merchant system, consistent withdisclosed embodiments.

DETAILED DESCRIPTION

Reference will now be made in detail to the disclosed embodiments,examples of which are illustrated in the accompanying drawings. Whereverconvenient, the same reference numbers will be used throughout thedrawings to refer to the same or like parts.

FIG. 1 is a block diagram of an exemplary system 100 for performing oneor more operations consistent with the disclosed embodiments. In oneembodiment, system 100 may include one or more financial serviceproviders 110, one or more merchants 120, one or more mobile devices130, and network 140. The components and arrangement of the componentsincluded in system 100 may vary. Thus, system 100 may include othercomponents that perform or assist in the performance of one or moreprocesses consistent with the disclosed embodiments.

Components of system 100 may be computing systems configured to providesystems and method for pre-authorizing a transaction request, consistentwith disclosed embodiments. As further described herein, components ofsystem 100 may include one or more computing devices (e.g., computer(s),server(s), etc.), memory storing data and/or software instructions(e.g., database(s), memory devices, etc.), and other known computingcomponents. In some embodiments, the one or more computing devices maybe configured to execute software instructions stored on one or morememory devices to perform one or more operations consistent with thedisclosed embodiments. Components of system 100 may be configured tocommunicate with one or more other components of system 100, includingsystems associated with financial service provider 110, merchant 120,and/or mobile device 130. In certain aspects, users (e.g., user 135) mayoperate one or more components of system 100 to initiate and provideinput for one or more operations consistent with the disclosedembodiments.

Financial service provider 110 may be an entity that provides,maintains, manages, or otherwise offers financial services. For example,financial service provider 110 may be a bank, credit card issuer, or anyother type of financial service entity that generates, provides,manages, and/or maintains financial service accounts for one or moreusers. Financial service accounts may include, for example, credit cardaccounts, loan accounts, checking accounts, savings accounts, reward orloyalty program accounts, and/or any other type of financial serviceaccount known to those skilled in the art. Financial service providersystem 110 may include infrastructure and components that are configuredto generate and/or provide financial service accounts such as creditcard accounts, checking accounts, debit card accounts, loyalty or rewardprograms, lines of credit, or the like. Consistent with certaindisclosed embodiments, financial service provider 110, using financialservice provider system 112, may provide manufacturer-based financialservice accounts, which may be financial service accounts that areassociated with a manufacturer of products or services, such as amerchant 120.

Financial service provider 110 may include one or more financial serviceprovider systems 112. In one aspect, financial service provider system112 may be one or more computing devices configured to perform one ormore operations consistent with disclosed embodiments. In one aspect,financial service provider system 112 may be a desktop computer, aserver, or any other type of computing device. Financial serviceprovider system 112 may include one or more processors configured toexecute software instructions stored in memory. The one or moreprocessors may be configured to execute software instructions that whenexecuted by a processor performs known Internet-related communicationand financial service-based processes. For instance, financial serviceprovider system 112 may execute software that provides data used forgenerating and displaying interfaces, including content on a displaydevice included in, or connected to, mobile device 130. Financialservice provider system 112 may also receive transaction requests frommerchant 120 and/or network 140, and may send these transaction requeststo fraud detection system 114 and/or card authorization system 116 forprocessing. Financial service provider system 112 may send responses tothe received transaction requests to mobile device 130, merchant 120,and/or network 140.

Financial service provider 110 may include one or more fraud detectionsystems 114. In one aspect, fraud detection system 114 may be one ormore computing devices configured to perform one or more operationsconsistent with disclosed embodiments. For example, fraud detectionsystem 114 may be a desktop computer, a server, or any other type ofcomputing device. Fraud detection system 114 may include one or moreprocessors configured to execute software instructions stored in memory.The one or more processors may be configured to execute softwareinstructions that when executed by the one or more processors performmethods that enable the detection of potentially fraudulent transactionrequests. For instance, fraud detection system 114 may receive atransaction request from financial service provider system 112 or cardauthorization system 116 and may determine whether the receivedtransaction request is potentially fraudulent.

Fraud detection system 114 may check the transaction request forfraudulence using known or as-yet-unknown processes—including thosebased on geographic location of merchant 120 or user 135, a dollaramount associated with the transaction request, a frequency or number oftransaction requests associated with user 135, etc. Checking thetransaction request may comprise generating a cumulative score relatingto each transaction request and comparing it to one or more thresholds.For example, fraud detection system 114 may utilize three thresholds todetermine fraudulence associated with a transaction request, such as afirst threshold representing the highest possible score for atransaction request, a second threshold representing the lowest score atwhich a transaction request that is not pre-authorized (e.g., where noassociated pre-authorization exists) can be approved, and/or a thirdthreshold representing the lowest score at which a pre-authorizedtransaction request can be approved. So, for example, if a transactionrequest is pre-authorized using mobile device 130, then the transactionrequest may be approved if an associated score is lower than the firstthreshold and the second threshold but higher than the third threshold,while a transaction request that is not pre-authorized may only beapproved if an associated score is lower than the first threshold buthigher than the second threshold. In some embodiments, fraud detectionsystem 114 may receive an indication from card authorization system 116indicative of whether a received transaction request is associated witha pre-authorization request.

In addition, in some embodiments, fraud detection system 114 may checkthe transaction request for different characteristics based on whetherthe transaction request is associated with a pre-authorization. Forexample, fraud detection system 114 may perform one set of checks ontransaction requests that are not associated with a pre-authorization,while fraud detection system 114 may perform only a subset of that setof checks on transaction requests that are associated with apre-authorization.

Financial service provider 110 may include one or more cardauthorization systems 116. In one aspect, card authorization system 116may be one or more computing devices configured to perform one or moreoperations consistent with disclosed embodiments. For example, cardauthorization system 116 may be a desktop computer, a server, or anyother type of computing device. Card authorization system 116 mayinclude one or more processors configured to execute softwareinstructions stored in memory. The one or more processors may beconfigured to execute software instructions that when executed by theone or more processors perform methods that enable the processing offinancial transaction authorization requests.

For instance, card authorization system 116 may receive a transactionrequest from fraud authorization system 114 and/or financial servicesystem 112, and determine whether a received transaction request matchesa pre-authorization. This comprises, for example, determining whether atransaction request includes a reference to a particular card or accountand/or whether that particular card or account is associated with apre-authorization. Determining whether a received transaction request isassociated with a pre-authorization also comprises, in some embodiments,determining whether a dollar value associated with the pre-authorizationis within some percentage (e.g., 10%) of a dollar value associated withthe transaction. Card authorization system 116 may also communicate tofraud detection system 114 whether or not a transaction request isassociated with a previously-requested pre-authorization and/or shouldbe authorized.

In some embodiments, one or both of fraud detection system 114 and cardauthorization system 116 may be configured to require that a transactionrequest be associated with a pre-authorization before approving thetransaction request. In other embodiments, one or both of frauddetection system 114 and card authorization system 116 may be configuredto require that transaction requests of a certain type (e.g., above acertain associated dollar value, at a particular merchant, associatedwith particular goods or services, or when merchant 120 or user 135 isin a particular geographic location) be associated with apre-authorization before approval.

Merchant 120 may be an entity that offers goods, services, and/orinformation, such as a retailer (e.g., Macys®, Target®, Amazon.com®,etc.), grocery store, service provider (e.g., utility company, etc.), orany other type of entity that offers goods, services, and/or informationthat consumers (e.g., end-users or other business entities, such as user135) may purchase, consume, use, etc. Merchant 120 may offer for saleone or more products of product manufacturer 120. In one example,merchant 120 may be associated with a brick and mortar retail location.In another example, merchant 120 may comprise an online merchant thatsells goods through the Internet or another network (such as network140). Merchant 120 may also include back- and/or front-end computingcomponents that store data and execute software instructions to performoperations consistent with disclosed embodiments, such as computers thatare operated by employees of the merchant (e.g., back office systems,etc.).

Merchant 120 may include merchant system 122. Merchant system 122 mayinclude one or more computing systems, such as server(s), desktopcomputers, etc., that are configured to execute stored softwareinstructions to perform operations associated with a merchant, includingone or more processes associated with processing purchase transactionrequests, generating transaction request data, generating product data(e.g., SKU data) relating to transaction requests, etc. Merchant system122 may perform one or more operations consistent with the disclosedembodiments. In one example, merchant system 122 may comprise apoint-of-sale device (for example, at a brick and mortar location). Inanother example, merchant system 122 is a web site operated by or onbehalf of merchant 120 that enables a consumer (e.g., user 135) toreceive information about goods or services for sale and initiate apurchase for those goods or services. The disclosed embodiments are notlimited to any particular configuration of merchant system 122.

Mobile device 130 may be one or more computing devices configured toperform one or more operations consistent with disclosed embodiments. inone example, mobile device 130 may be a tablet, a smart phone, acellular phone, a personal digital assistant (PDA), a media device (suchas an iPod®), or any other type of computing device. As mentionedherein, however, the disclosed embodiments are not limited to suchexamples.

Mobile device 130 may include one or more processors configured toexecute software instructions stored in memory, such as memory includedin mobile device 130. Mobile device 130 may include software that whenexecuted by a processor performs known Internet-related communication,content display processes, and financial service-related processes for auser of mobile device 130. For instance, mobile device 130 may executebrowser or related mobile display software that generates and displaysinterfaces including content on a display device included in, or incommunication with, mobile device 130. Mobile device 130 may executeapplications and/or communication software that allows mobile device 130to communicate with components over network 140, and generates anddisplays content in interfaces via a display device included in mobiledevice 130. The disclosed embodiments are not limited to any particularconfiguration of mobile device 130. In some embodiments, mobile device130 may be configured to execute software instructions relating tolocation services, such as determining a location using GPS or WiFi®networks. For example, mobile device 130 may be configured to determinea geographic location of mobile device 130 (and associated user 135) andprovide corresponding location data and time stamp data.

In some embodiments, mobile device 30 is configured to interact withmerchant 120 or merchant system 122 to effect a pre-authorization ortransaction request. This includes, for example, user 135 operatingmobile device 130 to browse a website hosted by merchant 120, mobiledevice 130 communicating card information to merchant system 122, or thelike.

Network 140 may be any type of network configured to providecommunications between components of system 100. For example, network140 may be any type of network (including infrastructure) that providescommunications, exchanges information, and/or facilitates the exchangeof information, such as the Internet, a Local Area Network, Near-FieldCommunication (NFC), Bluetooth, Optical code scanner, or other suitableconnection(s) that enables the sending and receiving of informationbetween the components of system 100. In other embodiments, one or morecomponents of system 100 may communicate directly through a dedicatedcommunication link(s), such as links between financial service provider110, merchant 120, and/or mobile device 130.

It is to be understood that the configuration and boundaries of thefunctional building blocks of system 100 have been defined herein forthe convenience of the description. Alternative boundaries can bedefined so long as the specified functions and relationships thereof areappropriately performed. Alternatives (including equivalents,extensions, variations, deviations, etc., of those described herein)will be apparent to persons skilled in the relevant art(s) based on theteachings contained herein. For example, financial service providersystem 112 and merchant system 122 may constitute a part of componentsof system 100 other than those specifically described, or may constitutea part of multiple components of system 100 (i.e., a distributedsystem).

FIG. 2 shows an exemplary electronic system 200 consistent withdisclosed embodiments. Variations of exemplary system 200 may be used toimplement portions or all of financial service provider 110, merchant120, and/or mobile device 130. In one embodiment, system 200 maycomprise one or more processors 221, one or more input/output (I/O)devices 222, and one or more memories 223. In some embodiments, system200 may take the form of a server, general purpose computer, mainframecomputer, or the like. In some embodiments, system 200 may take the formof a mobile computing device such as a smartphone, tablet, laptopcomputer, or the like. Alternatively, system 200 may be configured as aparticular apparatus, embedded system, dedicated circuit, or the like,based on the storage, execution, and/or implementation of the softwareinstructions that perform one or more operations consistent with thedisclosed embodiments.

Processor(s) 221 may include one or more known processing devices, suchas mobile device microprocessors, desktop microprocessors, servermicroprocessors, or the like. The disclosed embodiments are not limitedto a particular type of processor.

Memory 223 may include one or more storage devices configured to storeinstructions usable by processor 221 to perform functions related to thedisclosed embodiments. For example, memory 223 may be configured withone or more software instructions, such as program(s) 224 that performone or more operations when executed by processor 221. The disclosedembodiments are not limited to separate programs or computers configuredto perform dedicated tasks. For example, memory 223 may include a singleprogram or multiple programs that perform the functions of mobile device130. Memory 223 may also store data 225 that is used by one or moreprograms 224.

In certain embodiments, memory 223 may store software executable byprocessor(s) 221 to perform one or more methods, such as the methodsassociated with user interfaces in FIGS. 3A-3C and/or the methodsrepresented by the flowcharts depicted in FIGS. 4A and 4B.

I/O devices 222 may be one or more devices configured to allow data tobe received and/or transmitted by system 200. I/O devices 222 mayinclude one or more digital and/or analog devices that allow system 200to communicate with other machines and devices, such as other componentsof system 100. For example, I/O devices 222 may include a screen fordisplaying messages to user 135. I/O devices 222 may also include one ormore digital and/or analog devices that allow a user to interact withsystem 200 such as a touch-sensitive area, keyboard, buttons, ormicrophones. I/O devices 222 may also include other components known inthe art for interacting with a user. I/O devices 222 may also includeone or more hardware/software components for communicating with othercomponents of system 100. For example, I/O devices 222 may include awired network adapter, a wireless network adapter, a cellular networkadapter, or the like. Such network components enable system 200 tocommunicate with other systems to send and receive data.

The components of system 200 may be implemented in hardware, software,or a combination of both hardware and software, as will be apparent tothose skilled in the art. For example, although one or more componentsof system 200 may be implemented as computer processing instructions,all or a portion of the functionality of system 200 may be implementedinstead in dedicated electronics hardware.

FIG. 3A is a diagram of an exemplary interface 310 displaying choices ofcards that a user can use in accomplishing a pre-authorization request.In exemplary FIG. 3A, interface 310 is depicted as being displayed onmobile device 130 as part of a mobile wallet application. It is to beunderstood, however, that not all embodiments require interface 310 tobe implemented as part of a mobile wallet application. For example,interface 310 can be displayed on mobile device 130, a personalcomputer, or the like, as part of a web site hosted by financial serviceprovider system 112.

Mobile device 130 may present interface 310 to user 135, enabling user135 to select which card will be used in an upcoming transaction. Cards320A-320D may constitute credit cards, debit cards, charge cards, otherpayment cards, stored value cards, or other cards. In alternativeembodiments, cards 320A-320D may include non-card accounts as well,including charge accounts, checking accounts, savings accounts, lines ofcredit, or the like.

In some embodiments, mobile device 130 may present interface 310 to user135 when user 135 opens the mobile wallet application, opens anotherapplication, opens a web site to select a card, and/or performs someother action that indicates that user 135 may desire to make a purchase.

User 135 may select one of cards 320A-320D by actuating the selectedcard (e.g., by pressing on a screen on mobile device 130 or moving akeypad to select the desired card). Interface 310 may then receive apress at button 330 to select that card for the transaction. In someembodiments, after receiving a press at button 330, the next interfaceshown on mobile device 130 may include another interface, such as theinterface depicted in FIG. 3B, while in other embodiments, the nextinterface shown on mobile device 130 may be the interface depicted inFIG. 3C.

FIG. 3B is a diagram of an exemplary interface 311 requesting anapproximate amount for a pre-authorization request, consistent withdisclosed embodiments. In exemplary FIG. 3B, interface 311 is depictedas being displayed on mobile device 130 as part of a mobile walletapplication. It is to be understood, however, that not all embodimentsrequire interface 311 to be implemented as part of a mobile walletapplication. For example, interface 311 can be displayed on mobiledevice 130, a personal computer, or the like, as part of a web sitehosted by financial service provider system 112. According to someembodiments, mobile device 130 may further present an interface (notshown) requesting an indication of the merchant with which user 135intends to complete a transaction and/or a location (e.g., a zip code,location, or website) where user 135 intends to complete thetransaction.

In some embodiments, interface 311 may be presented to user 135 afteruser 135 has selected a card 320A-320D and pressed button 330, as shownin FIG. 3A. Interface 311 may include a dollar field 340, a set of uparrows 341, a set of down arrows 342, a submit button 360, and/or a backbutton 361.

Interface 311 may receive a selection from user 135 regarding anapproximate amount for an upcoming transaction request. While in somesituations user 135 will not know an exact amount of an upcomingtransaction (because of, for example, tax or shipping and handling),user 135 may be able to guess within 10% of the actual amount for thetransaction. Thus, in some embodiments, interface 311 may provide uparrows 341 and down arrows 342 to enable user 135 to select anapproximate dollar amount within, for example, 10% of the actual amountof an upcoming transaction. In other embodiments, interface 311 mayreceive inputted digits in dollar field 340 to indicate approximatelyhow much user 135 believes the transaction will be. Upon receipt of abutton press at button 360, mobile device 130 may send the card selectedin FIG. 3A (e.g., one of cards 320A-320D) and the value in dollar field340. Alternatively, interface 311 may receive a button press at button361, if, for example, user 135 selected an incorrect card from cards320A-320D and desires to select a different card. Pressing button 361,in some embodiments presents interface 310 in FIG. 3A to user 135.

FIG. 3C is a diagram of an exemplary interface 312 displaying aconfirmation that a pre-authorization request has been approved,consistent with disclosed embodiments. In exemplary FIG. 3C, interface312 is depicted as being displayed on mobile device 130 as part of amobile wallet application. It is to be understood, however, that not allembodiments require interface 312 to be implemented as part of a mobilewallet application. For example, interface 312 can be displayed onmobile device 130, a personal computer, or the like, as part of a website hosted by financial service provider system 112.

In some embodiments, interface 312 may be presented to user 135 afteruser 135 has selected a card 320A-320D and pressed button 330, as shownin FIG. 3A. In other embodiments, interface 312 may be presented to user135 after user 135 has selected a card as in FIG. 3A and/or input anapproximate dollar value in dollar field 340 as shown in FIG. 3B.Interface 312 may include confirmation 370 and button 371.

Confirmation 370 may serve to inform user 135 that a pre-authorizationrequest has been approved. This may give user 135 confidence that afuture transaction corresponding to the parameters associated with thepre-authorization request (e.g. the particular card selected and/or adollar value specified) will be approved, which may serve to preventdenial of a transaction that would otherwise appear potentiallyfraudulent. Confirmation 370 may also include validity period, whichindicates how long the approval is valid for.

FIG. 3D is a diagram of exemplary interface 313 displaying a denial of apre-authorization request, consistent with disclosed embodiments. Inexemplary FIG. 3D, interface 313 is depicted as being displayed onmobile device 130 as part of a mobile wallet application. It is to beunderstood, however, that not all embodiments require interface 313 tobe implemented as part of a mobile wallet application. For example,interface 313 can be displayed on mobile device 130, a personalcomputer, or the like, as part of a web site hosted by financial serviceprovider system 112.

In some embodiments, interface 313 may be presented to user 135 haveuser 135 has selected a card 320A-320D and pressed button 330, as shownin FIG. 3A. In other embodiments, interface 313 may be presented to user135 after user 135 has selected a card as in FIG. 3A and/or input anapproximate dollar value in dollar field 340 as shown in FIG. 3B.Interface 313 may include denial 380 and button 381.

Denial 380 may serve to inform user 135 that a pre-authorization requesthas been denied. Denial of a pre-authorization request could occurbecause an approximate dollar value associated with thepre-authorization request exceeds a pre-set amount associated with thecard or account, because a transaction with the approximate dollaramount would exceed a credit limit associated with the card or account,because the card or account is closed or suspended, because thepre-authorization request appears fraudulent, or the like. According tosome embodiments, denial 380 may further provide one or more reason(s)why the pre-authorization request was denied (e.g., thepre-authorization request indicated a dollar amount that would exceedthe credit limit associated with the card or account, the card has beenreported as stolen or missing, and/or any other factor capable ofraising the risk of fraud, default, etc.).

In some embodiments, denial 380 may inform user 135 that furtherauthorization is required from user 135. For example, if apre-authorization request appears fraudulent, interface 313 may presentbutton to enable user 135 to provide further information in order toauthenticate the pre-authentication request. Interface 313 may receive apress at button 381 and proceed to a new interface (not pictured) toreceive further authentication from user 135, such as a password, a PIN,biometric identification, or the like. In other embodiments, denial 380may present a phone number which, if dialed by user 135, connects user135 to a pre-recorded message informing user 135 why thepre-authorization request was denied and/or connects user 135 to a liveoperator that can assist the user in obtaining a confirmation for thepre-authorization request.

FIG. 4A is a flowchart of an exemplary process 400 for pre-authorizing atransaction request. In step 401, an application (such as a mobilewallet application or web site) may be initialized by mobile device 130.Mobile device 130, in step 403, may prompt user 135 to select a card oraccount with which user 135 is intending on making a purchase via, forexample, interface 310 in FIG. 3A. As explained above with reference toFIG. 3A, mobile device 130 may present a set of cards and may receive aselection of at least one of those cards (or accounts) for use with anupcoming transaction.

In step 404, mobile device 130 may prompt user 135 to input anapproximate amount for the upcoming transaction. As explained above withreference to FIG. 3B, the approximate amount may be received in avariety of input means. After inputting the approximate amount, process400 may continue to step 405. Step 404, however is optional and may notbe executed in all embodiments. In those embodiments, process 400 canproceed directly from step 403 to 405.

After prompting user 135 to select a card or account (step 403) and/orprompting user 135 to input an approximate amount for the upcomingtransaction (step 404), in step 405, mobile device 130 may generate apre-authorization request for sending to card authorization system 116.The pre-authorization request may include the selected card or account(from step 403), an approximate amount for the upcoming transaction(from step 404), and/or a location of mobile device 130 (e.g., ageographic location such as latitude or longitude coordinates or anaddress). Mobile device 130 may also send that pre-authorization requestto card authorization system 116.

In step 407, card authorization system 116 may receive thepre-authorization request. In step 409, card authorization system 116may perform a set of validity checks on the received pre-authorizationrequest. For example, card authorization system 116 may attempt toverify the identity of user 135 or mobile device 130, may examine thepre-authorization request for data transmission or security issues, maydetermine whether the card or account referenced in thepre-authorization request is in good standing (e.g., not overdrawn,unpaid, or charged off), may determine whether the dollar valuereferenced in the pre-authorization request would cause the card oraccount to exceed a credit limit, or the like.

If card authorization system 116 determines that the pre-authorizationrequest is valid and should be granted, then in step 411, cardauthorization system 116 may generate a pre-authorization for sending tomobile device 130. The pre-authorization includes, for example, anapproval number that indicates to mobile device 130 and user 135 thatthe pre-authorization request was granted. In some embodiments,pre-authorizations are also associated with a time stamp that indicatesa validity period, after which the pre-authorization will “expire” andno longer be valid. So, if a transaction request is received and anassociated pre-authorization has expired, the transaction request willnot be determined to be “associated” with that pre-authorization.

Card authorization system 116 may send an indication of thepre-authorization to mobile device 130. In step 413, mobile device 130may receive the pre-authorization. Mobile device may, as explained abovewith reference to FIG. 3C, present an indication to user 135 that thepre-authorization was received. This gives user 135 confidence that atransaction in line with the parameters associated with thepre-authorization request sent in step 405 will be approved, which mayserve to prevent denial of a transaction even if the transactionotherwise appears potentially fraudulent.

FIG. 4B is a flowchart of an exemplary process 410 for processing atransaction request initiated at merchant system 122. In step 421,merchant system 122 may initialize a transaction. This may comprise, forexample, receiving physical items from user 135 for scanning at aphysical point-of-sale device, determining items added to an onlineshopping cart by user 135, or the like. Step 421 may also comprisereceiving a card or account identifier that user 135 wishes to use topay for the transaction. This includes, for example, receiving aphysical payment card and swiping it through a magnetic swipe reader,receiving an NFC-based communication that includes a payment cardnumber, receiving an a card number entered by user 135 on a web siteassociated with merchant device 122, or the like.

In step 423, merchant system 122 may generate a transaction request andsend it to financial service provider system 112. The transactionrequest may include a card or account that user 135 is attempting to useto effect the transaction, a dollar values associated with thetransaction, a location of merchant 122 (e.g., a geographic locationsuch as latitude and longitude coordinates or a street address, andother information as necessary (e.g., authentication information). Instep 425, financial service provider 112 may receive the transactionrequest and forward it to the appropriate subsystem, e.g., cardauthorization system 116.

In step 427, card authorization system 116 may determine whether thereceived transaction is associated with a pre-authorization. Cardauthorization system 116 may determine that a transaction is associatedwith a pre-authorization if, for example, the received transactionincludes a reference to a card or account that is associated with apre-authorization.

Determining that a received transaction is associated with apre-authorization may also comprise, in some embodiments, determiningwhether a dollar value associated with the received transaction iswithin some percentage of a dollar value associated with apre-authorization. As one example, card authorization system 116 maydetermine that a received transaction is only associated with apre-authorization if the received transaction references a card alsoreferenced by the pre-authorization and is within 15% of a dollar valueassociated with the pre-authorization. Otherwise, card authorizationsystem 116 may determine that the received transaction is not associatedwith that pre-authorization. As another example, card authorizationsystem 116 may determine that a received transaction is only associatedwith a pre-authorization if the transaction is within some percentage ofa dollar value associated with the pre-authorization, the percentagebeing based on the amount of the pre-authorization. For example, apre-authorization for less than $1,000.00 would be associated with atransaction if the transaction and pre-authorization differed by lessthan 10%, while a pre-authorization for more than $1,000.00 would beassociated with a transaction if the transaction and pre-authorizationdiffered by less than 5%.

Determining that a received transaction is associated with a particularpre-authorization may also comprise, in some embodiments, determiningwhether the current date and time are within a validity periodassociated with the pre-authorization. For example, thepre-authorization may be associated with a 30-minute or one-day windowduring which transaction requests can be “associated” with thepre-authorization. Conversely, if the transaction request is receivedoutside of that window, card authorization system 116 may determine thatthe transaction request is not associated with the pre-authorization.

Determining that a received transaction is associated with a particularpre-authorization may also comprise, in some embodiments, determiningwhether a location of merchant 122 included in the transaction requestis within some distance of a location of mobile device 130 associatedwith the pre-authorization.

In some embodiments, step 427 may also comprise card authorizationsystem 116 determining whether the card or account referenced in thetransaction is in good standing (e.g., not overdrawn, unpaid, or chargedoff), determining whether the dollar value referenced in the transactionwould cause the card or account to exceed a credit limit, or the like.(Card authorization system 116 may be configured in these embodiments tosend an indication to financial service provider system 112 indicatingthat the transaction should be denied.)

In situations where a received transaction is not associated with apre-authorization, card authorization system 116 may send thetransaction to fraud detection system 114 with an indication that it isnot associated with a pre-authorization. In step 429, fraud detectionsystem 114 may determine whether the transaction passes fraud checks.This includes, for example, determining whether the transaction is anoutlier from previous transactions (e.g., is received from a merchantthat user 135 does not frequent, is received from a merchant in ageographic area that user 135 is not known to frequent, contains adollar value significantly higher than other transactions associatedwith user 135) or otherwise appears fraudulent.

In some embodiments determining whether a transaction passes fraudchecks comprises fraud detection system 114 generating a cumulativescore associated with the transaction. For example, a cumulative scoreassociated with the transaction may be based on a multitude of aspectsassociated with the transaction, each aspect being associated with ascore reflective of whether that aspect indicates that the transactionrequest is fraudulent. Example aspects include a number of transactionsperformed in the past 24 hours, a distance between a location associatedwith a current transaction request and the last five transactions, adifference in dollar value between this transaction and the previous 10transactions, or the like. In some embodiments, the more likely that aparticular aspect is to make the transaction appear fraudulent, thehigher a score associated with the aspect. The scores associated witheach aspect may then be added together to obtain the cumulative score. Ahigher cumulative score may represent a greater likelihood that theassociated transaction is fraudulent. For example, a score between 0 and500 may be considered as “not likely fraudulent,” a score of 501 to 1000may be considered as “likely fraudulent,” and a score above 1000 may beconsidered as “fraudulent.” (It is to be understood, however, that notall embodiments require these particular scores.)

If fraud detection system 114 generates a score associated with atransaction and determines that the score is outside of an acceptablerange (e.g., higher than a range of scores associated with “not likelyfraudulent” transactions), fraud detection system 114 may determine thatthe transaction is likely fraudulent and should be denied, and forwardsthe transaction with that indication to financial service providersystem 112. For example, if the transaction is not associated with apre-authorization, fraud detection system may determine that thetransaction is likely fraudulent if an associated score is 501 or above.Financial service provider system 112 may generate a denial (step 431)and send it to merchant system 112, which receives the denial in step435. (User 135 can then be informed that the transaction was denied, andcan retry the transaction, contact financial service provider 110, ortake other actions.)

If, on the other hand, the cumulative score generated by fraud detectionsystem 114 is within an acceptable range (e.g., between 1 and 500),fraud detection system 114 may determine that the transaction is notlikely to be fraudulent and should be approved, and forwards thetransaction with an indication that it should be approved to financialservice provider system 112. Financial service provider system 112 maygenerate an approval (step 433) and send it to merchant system 112,which receives it in step 435.

If, however, in step 427, card authorization system 116 determines thata received transaction is associated with a pre-authorization, then, insome embodiments, card authorization system 116 may determine that thetransaction should be approved. Card authorization system 116 mayforward the transaction with an indication that it should be approved tofinancial service provider system 112. Financial service provider system112 may generate an approval (step 433) and send it to merchant system112, which receives it in step 435.

In some embodiments, however, if card authorization system 116determines that a received transaction is associated with apre-authorization, card authorization system 116 sends an indication tofraud detection system 114 to perform fraud checks on the transaction.Fraud detection system 114 may perform a set of validity checks ontransactions that are not associated with a pre-authorization, whilefraud detection system 114 may perform only a subset of those validitychecks on transactions that are associated with a pre-authorization. Inother embodiments, fraud detection system 114 may generate a cumulativescore associated with the transaction and determine that the transactionis not fraudulent so long as the cumulative score is not higher thansome threshold (e.g., higher than a range of scores associated with“fraudulent” transactions).

The foregoing description has been presented for purposes ofillustration. It is not exhaustive and is not limited to the preciseforms or embodiments disclosed. Modifications and adaptations of theembodiments will be apparent from consideration of the specification andpractice of the disclosed embodiments. For example, the describedimplementations include hardware and software, but systems and methodsconsistent with the present disclosure can be implemented as hardwarealone. Furthermore, although aspects of the disclosed embodiments aredescribed as being associated with data stored in memory and othertangible computer-readable storage mediums, one skilled in the art willappreciate that these aspects can also be stored on and executed frommany types of tangible computer-readable media, such as secondarystorage devices, like hard disks, floppy disks, or CD-ROM, or otherforms of RAM or ROM.

Computer programs based on the written description and methods of thisspecification are within the skill of a software developer. The variousprograms or program modules can be created using a variety ofprogramming techniques. For example, program sections or program modulescan be designed in or by means of Java, C, C++, assembly language, Perl,PHP, HTML, or other programming languages. One or more of such softwaresections or modules can be integrated into a computer system,computer-readable media, or existing communications software.

Moreover, while illustrative embodiments have been described herein, thescope includes any and all embodiments having equivalent elements,modifications, omissions, combinations (e.g., of aspects across variousembodiments), adaptations or alterations based on the presentdisclosure. The elements in the claims are to be interpreted broadlybased on the language employed in the claims and not limited to examplesdescribed in the present specification or during the prosecution of theapplication, which examples are to be construed as non-exclusive.Further, the steps of the disclosed methods can be modified in anymanner, including by reordering steps or inserting or deleting steps. Itis intended, therefore, that the specification and examples beconsidered as example only, with a true scope and spirit being indicatedby the following claims and their full scope of equivalents.

What is claimed is:
 1. A system for authorizing transactions,comprising: at least one processing device; and at least one storagemedium comprising instructions that when executed cause the at least oneprocessing device to perform a method comprising: receiving, over anetwork, a transaction request from a first device, the transactionrequest comprising a merchant location, a requested payment method, anda transaction amount; determining, via a global positioning system, thatthe merchant location is within a threshold distance of a location of asecond device that generated a pre-authorization for a transaction,wherein the pre-authorization comprises a pre-authorized amount for apre-authorized payment method; determining, based on comparing therequested payment method and the pre-authorized payment method, that thetransaction request matches the pre-authorization; and in response todetermining that the transaction request matches the pre-authorization,processing the transaction request for the transaction.
 2. The system ofclaim 1, wherein receiving the transaction request comprises receivingthe transaction request from the first device associated with amerchant.
 3. The system of claim 1, wherein the pre-authorizationfurther comprises a pre-authorized location.
 4. The system of claim 3,wherein the method performed by the at least one processing devicefurther comprises: receiving, from the second device, location dataindicative of a current location of the second device, wherein thesecond device is associated with a user.
 5. The system of claim 3,wherein the pre-authorized location is associated with the merchantlocation.
 6. The system of claim 1, wherein the pre-authorizationcomprises a pre-authorized validity period.
 7. The system of claim 6,wherein the method performed by the at least one processing devicefurther comprises: receiving, from the second device, a timestampassociated with the transaction request, the timestamp comprising adate; determining whether the date is within the pre-authorized validityperiod; and processing the transaction request when the date is withinthe pre-authorized validity period.
 8. The system of claim 1, whereinprocessing the transaction request comprises transmitting an indicationthat the transaction request is approved to a financial service providerassociated with the requested payment method.
 9. The system of claim 1,wherein the pre-authorized payment method is selected by a user via amobile wallet application on the second device.
 10. The system of claim1, wherein the method performed by the at least one processing devicefurther comprises: determining that the transaction request does notmatch the pre-authorization; and processing the transaction request whena fraud score associated with the transaction request is less than athreshold.
 11. A computer-implemented method for authorizing atransaction, comprising: receiving, over a network, a transactionrequest for the transaction from a first device, the transaction requestcomprising a merchant location, a requested payment method, and atransaction amount; determining, via a global positioning system, thatthe merchant location is within a threshold distance of a location of asecond device, wherein the second device generates a pre-authorizationfor the transaction, wherein the pre-authorization comprises apre-authorized amount for a pre-authorized payment method; determining,based on comparing the requested payment method and the pre-authorizedpayment method, that the transaction request matches thepre-authorization; and in response to determining that the transactionrequest matches the pre-authorization, processing the transactionrequest for the transaction.
 12. The computer-implemented method ofclaim 11, further comprising: receiving, from the second device,location data indicative of a current location of the second device,wherein the second device is associated with a user.
 13. Thecomputer-implemented method of claim 11, wherein the transaction requestfurther comprises at least one of a geographic location, a validityperiod, or an indication of a merchant.
 14. The computer-implementedmethod of claim 11, further comprising: determining whether thetransaction is within a percentage of the pre-authorized amount.
 15. Thecomputer-implemented method of claim 14, wherein the percentage isassociated with an estimated tax on the pre-authorized amount.
 16. Thecomputer-implemented method of claim 15, wherein the percentage ispre-configured by a user associated with the pre-authorization.
 17. Thecomputer-implemented method of claim 11, further comprising:determining, based on a balance associated with the requested paymentmethod, whether processing the transaction request will cause thebalance to exceed a credit limit associated with the requested paymentmethod; and processing the transaction request when the credit limit isnot exceeded.
 18. The computer-implemented method of claim 11, whereinthe pre-authorized payment method is selected by a user via a mobilewallet application on the second device.
 19. The computer-implementedmethod of claim 11, further comprising: determining that the transactionrequest does not match the pre-authorization; and processing thetransaction request when a fraud score associated with the transactionrequest is less than a threshold.
 20. A non-transitory computer-readablemedium system comprising instructions that, when executed by one or moreprocessors, cause operations for authorizing a transaction, comprising:receiving, over a network, a transaction request for the transactionfrom a first device, the transaction request comprising a merchantlocation, a requested payment method, and a transaction amount;determining, via a global positioning system, that the merchant locationis within a threshold distance of a location associated with a user of asecond device that generated a pre-authorization for the transaction,wherein the pre-authorization comprises a pre-authorized amount for apre-authorized payment method; determining, based on comparing therequested payment method and the pre-authorized payment method, that thetransaction request matches the pre-authorization; and in response todetermining that the transaction request matches the pre-authorization,processing the transaction request for the transaction.